# 实战篇 03：页面布局方案

本节参考代码：

react-boilerplate-pro/src/layouts/BasicLayout.jsx

react-boilerplate-pro/src/layouts/NormalLayout.jsx

react-acl-router/src/AclRouter.jsx

在传统的前端开发中提到布局我们可能第一时间会想到「圣杯布局」或「双飞燕布局」这些跟 CSS 相关的页面布局方式。而在现代前端开发中，更准确地说在组件化开发逐渐成为现代前端开发主流之后对于布局这一概念又有了新的定义，那就是多个页面中共同的部分，也可以叫做页面的骨架。

如下图，在不同页面中都会包含的侧边栏菜单就是页面基础布局的一部分：

# 布局与路由

在讨论具体的布局组件设计前，我们首先要解决一个更为基础的问题，那就是如何将布局组件与应用路由结合起来。

下面的这个例子是 react-router 官方提供的侧边栏菜单与路由结合的例子，笔者这里做了一些简化：

const SidebarExample = () => (
  <Router>
    <div style={{ display: "flex" }}>
      <div
        style={{
          padding: "10px",
          width: "40%",
          background: "#f0f0f0"
        }}
      >
        <ul style={{ listStyleType: "none", padding: 0 }}>
          <li>
            <Link to="/">Home</Link>
          </li>
          <li>
            <Link to="/bubblegum">Bubblegum</Link>
          </li>
          <li>
            <Link to="/shoelaces">Shoelaces</Link>
          </li>
        </ul>
      </div>

      <div style={{ flex: 1, padding: "10px" }}>
        {routes.map((route, index) => (
          <Route
            key={index}
            path={route.path}
            exact={route.exact}
            component={route.main}
          />
        ))}
      </div>
    </div>
  </Router>
);

@前端进阶之旅: 代码已经复制到剪贴板

抽象为布局的思想，写成简单的伪代码就是：

<Router>
  <BasicLayout>                   // with sidebar
    {routes.map(route => (
      <Route {...route} />
    ))}
  </BasicLayout>
</Router>

@前端进阶之旅: 代码已经复制到剪贴板

这样的确是一种非常优雅的解决方案，但它的局限性在于无法支持多种不同的布局。受限于一个 Router 只能包含一个子组件，即使我们将多个布局组件包裹在一个容器组件中，如：

<Router>
  <div>
    <BasicLayout>                 // with sidebar
      {routes.map(route => (
      	<Route {...route} />
      )}
    </BasicLayout>
    <FlexLayout>                  // with footer
      {routes.map(route => (
        <Route {...route} />
      )}
    </FlexLayout>
  </div>
</Router>

@前端进阶之旅: 代码已经复制到剪贴板

路由在匹配到 FlexLayout 下的页面时，BasicLayout 中的 sidebar 也会同时显示出来，这显然不是我们想要的结果。换个思路，我们可不可以将布局组件当做 children 直接传给更底层的 Route 组件呢？代码如下：

<Router>
  <div>
    {basicLayoutRoutes.map(route => (
      <Route {...route}>
        <BasicLayout component={route.component} />
      </Route>
    ))}
    {flexLayoutRoutes.map(route => (
      <Route {...route}>
        <FlexLayout component={route.component} />
      </Route>
    ))}
  </div>
</Router>

@前端进阶之旅: 代码已经复制到剪贴板

这里我们将不同的布局组件当做高阶组件，相应地包裹在了不同的页面组件上，这样就实现了对多种不同布局的支持。还有一点需要注意的是，react-router 默认会将 match、location、history 等路由信息传递给 Route 的下一级组件，由于在上述方案中，Route 的下一级组件并不是真正的页面组件而是布局组件，因而我们需要在布局组件中手动将这些路由信息传递给页面组件，或者统一改写 Route 的 render 方法为：

<Route
  render={props => (                 // props contains match, location, history
    <BasicLayout {...props}>
      <PageComponent {...props} />
    </BasicLayout>
  )}
/>

@前端进阶之旅: 代码已经复制到剪贴板

另外一个可能会遇到的问题是，connected-react-router 并不会将路由中非常重要的 match 对象（包含当前路由的 params 等数据）同步到 redux store 中，所以我们一定要保证布局及页面组件在路由部分就可以接收到 match 对象，否则在后续处理页面页眉等与当前路由参数相关的需求时就会变得非常麻烦。

# 页眉 & 页脚

解决了与应用路由相结合的问题，具体到布局组件内部，其中最重要的两部分就是页面的页眉和页脚部分，而页眉又可以分为应用页眉与页面页眉两部分。

应用页眉指的是整个应用层面的页眉，与具体的页面无关，一般来说会包含用户头像、通知栏、搜索框、多语言切换等这些应用级别的信息与操作。页面页眉则一般来讲会包含页面标题、面包屑导航、页面通用操作等与具体页面相关的内容。

在以往的项目中，尤其是在项目初期许多开发者因为对项目本身还没有一个整体的认识，很多时候会倾向于将应用页眉做成一个展示型组件并在不同的页面中直接调用。这样做当然有其方便之处，比如说页面与布局之间的数据同步环节就被省略掉了，每个页面都可以直接向页眉传递自己内部的数据。

但从理想的项目架构角度来讲这样做却是一个反模式（anti-pattern）。因为应用页眉实际是一个应用级别的组件，但按照上述做法的话却变成了一个页面级别的组件，伪代码如下：

<App>
  <BasicLayout>
    <PageA>
      <AppHeader title="Page A" />
    </PageA>
  </BasicLayout>
  <BasicLayout>
    <PageB>
      <AppHeader title="Page B" />
    </PageB>
  </BasicLayout>
</App>

@前端进阶之旅: 代码已经复制到剪贴板

从应用数据流的角度来讲也存在着同样的问题，那就是应用页眉应该是向不同的页面去传递数据的，而不是反过来去接收来自页面的数据。这导致应用页眉丧失了控制自己何时 rerender（重绘) 的机会，作为一个纯展示型组件，一旦接收到的 props 发生变化页眉就需要进行一次重绘。

另一方面，除了通用的应用页眉外，页面页眉与页面路由之间是有着严格的一一对应的关系的，那么我们能不能将页面页眉部分的配置也做到路由配置中去，以达到新增加一个页面时只需要在 config/routes.js 中多配置一个路由对象就可以完成页面页眉部分的创建呢？理想情况下的伪代码如下：

<App>
  <BasicLayout>                    // with app & page header already
    <PageA />
  </BasicLayout>
  <BasicLayout>
    <PageB />
  </BasicLayout>
</App>

@前端进阶之旅: 代码已经复制到剪贴板

# 配置优于代码

在过去关于组件库的讨论中我们曾经得出过代码优于配置的结论，即需要使用者自定义的部分，应该尽量抛出回调函数让使用者可以使用代码去控制自定义的需求。这是因为组件作为极细粒度上的抽象，配置式的使用模式往往很难满足使用者多变的需求。但在企业管理系统中，作为一个应用级别的解决方案，能使用配置项解决的问题我们都应该尽量避免让使用者编写代码。

配置项（配置文件）天然就是一种集中式的管理模式，可以极大地降低应用复杂度。以页眉为例来说，如果我们每个页面文件中都调用了页眉组件，那么一旦页眉组件出现问题我们就需要修改所有用到页眉组件页面的代码。除去 debug 的情况外，哪怕只是修改一个页面标题这样简单的需求，开发者也需要先找到这个页面相对应的文件，并在其 render 函数中进行修改。这些隐性成本都是我们在设计企业管理系统解决方案时需要注意的，因为就是这样一个个的小细节造成了本身并不复杂的企业管理系统在维护、迭代了一段时间后应用复杂度陡增。理想情况下，一个优秀的企业管理系统解决方案应该可以做到 80% 以上非功能性需求变更都可以使用修改配置文件的方式解决。

# 配置式页眉

import { matchRoutes } from 'react-router-config';

// routes config
const routes = [{
  path: '/outlets',
  exact: true,
  permissions: ['admin', 'user'],
  component: Outlets,
  unauthorized: Unauthorized,
  pageTitle: '门店管理',
  breadcrumb: ['/outlets'],
}, {
  path: '/outlets/:id',
  exact: true,
  permissions: ['admin', 'user'],
  component: OutletDetail,
  unauthorized: Unauthorized,
  pageTitle: '门店详情',
  breadcrumb: ['/outlets', '/outlets/:id'],
}];

// find current route object
const pathname = get(state, 'router.location.pathname', '');
const { route } = head((matchRoutes(routes, pathname)));

@前端进阶之旅: 代码已经复制到剪贴板

基于这样一种思路，我们可以在通用的布局组件中根据当前页面的 pathname 使用 react-router-config 提供的 matchRoutes 方法来获取到当前页面 route 对象的所有配置项，也就意味着我们可以对所有的这些配置项做统一的处理。这不仅为处理通用逻辑带来了方便，同时对于编写页面代码的同事来说也是一种约束，能够让不同开发者写出的代码带有更少的个人色彩，方便对于代码库的整体管理。

# 页面标题

# 面包屑导航

# 知识点：组件与 redux

在以上的讨论中我们发现布局组件与应用路由之间有着千丝万缕的联系，那么我们能不能抽象出一个通用的布局组件并直接将它作为应用路由的一部分包含在路由中呢？这样开发者在使用这个「高级路由」时，只需要配置每个页面的路由属性就可以自动获得页面的基础布局，岂不是非常方便？

延伸来讲，一个组件如果必须要 connect 到 redux store 后才能使用的话，严格意义上来说它就不再是一个组件了，因为这时它就对自己所处的上下文环境有了要求，一旦脱离了当前应用它就无法再顺利地完成自身内部的一些功能，组件所应当拥有的可复用性也就不存在了。